fix: table view edit/delete without PK, toolbar icons, 9 database actions - #116

COLUMN_KEY extraction used index 7 (row.get_opt(7)) which silently fails
in mysql_async 0.34 due to column ordering quirk. Switched to name-based
access row.get_opt("COLUMN_KEY") which is more robust.

Also added: console diagnostics in DataTableView when PK detection fails,
so users can see what list_columns returns for debugging.

The existing fallback (edit/delete using all columns when no PK detected)
is kept as safety net for adapters like HttpSql that don't support
list_columns at all.

…N_KEY

INFORMATION_SCHEMA.COLUMNS.COLUMN_KEY relies on mysql_async's
FromValue<String> conversion which can fail silently depending on
the MySQL server's charset/collation settings for the INFORMATION_SCHEMA
virtual tables, causing PKs to never be detected.

Fix: query KEY_COLUMN_USAGE with CONSTRAINT_NAME = 'PRIMARY' in a
separate query to build a HashSet of PK column names, then check
each column against it. This is the same approach DBeaver uses
via JDBC's DatabaseMetaData.getPrimaryKeys().

…tness

mysql_async's FromValue<String> can silently fail on INFORMATION_SCHEMA
virtual table columns because they use a different character set than
user tables. This caused COLUMN_KEY to always read as empty string,
making PK detection fail for ALL MySQL tables.

Fix: add get_str() / get_str_by_name() / get_opt_str() helpers that try
FromValue<String> first, then fall back to FromValue<Vec<u8>> +
String::from_utf8_lossy(). This ensures string column values are
always correctly decoded regardless of charset quirks.

Applied to all string column reads in list_columns (COLUMN_NAME,
DATA_TYPE, IS_NULLABLE, COLUMN_DEFAULT, COLUMN_KEY, EXTRA, COLUMN_COMMENT).

- CreateDatabaseDialog: MySQL gets charset dropdown + collation input;
  PostgreSQL gets encoding dropdown + locale input; other DBs get
  name-only (same as before)
- CreateTableDialog: MySQL gets ENGINE dropdown (InnoDB/MyISAM/MEMORY/...)
- CreateObjectDialog kept for Create Schema (no extra options needed)
- i18n: enUS + zhCN for all new fields
- QueriesPage passes activeConnection.type to dialogs for type-aware UI
- Sidebar index exports CreateDatabaseDialog

ApiResponse is a tagged enum ({"status":"success"|"error"}) not a
struct with a boolean success field. The old check `result.success ===
false` was always false (field didn't exist), so ALL backend errors
were silently swallowed — including failed CREATE DATABASE.

Fix: use `isApiSuccess(result)` which checks `result.status ===
'success'` correctly.

Also: replace schemaTreeRef.refresh() with direct fetchDatabases()
after create/drop database, so the tree doesn't switch to Mode A.

Each database type has different identifier quoting:
- MySQL-compat: backticks ()
- PostgreSQL-compat: double quotes ("name")
- SQL Server: square brackets ([name])
- Others: unquoted

Also only appends options relevant to the database type
(CHARACTER SET/COLLATE for MySQL, ENCODING/LC_COLLATE for PG).